Subject: Names in ACTLU/ACTPU

From: David Bryant/HQ/3Com <[email-masked]>
Date: 18 Dec 95 10:21:17 EDT

Just wanted to clarify why I feel an XID3 based solution is insufficient...

Many of us are in the legacy device support business.  We support the many 
older PU2 devices (both IBM and clone) in networks today.   Often times 
customers wish to install new communications infrastructure and accommodate the 
legacy devices UNCHANGED.   Thus any solution which requires a change to the 
legacy device is certainly very undesirable if not unacceptable.  Since the 
vast majority of legacy devices do not send XID3, I view any solution based 
upon XID3 unacceptable. 

To be more specific on my concerns, let me describe the scenario which I am 
trying to address:

PU2----------device1===network=====device2--------PU4/5

In both DLSw and APPN/DLUr, a device connects to a  PU2 and it's intent is to 
provide legacy device support.  In both cases, "device1" is intelligent enough 
to know it needs naming information in ACTPU/ACTLU in order to correlate SNA 
PU/LU information with the internal networking protocols (DLSw or APPN) that is 
being used between device1 and device2.    It can intercept the 'vanilla' PU2 
flows and modify them such that the message received at PU4/5 from device2 
indicates the need for names in ACTPU/LU.  When the resultant flows are sent 
down to PU2, device1 can strip them off.  

I think that changes to XID0/2 can be easily accommodated.  But a change 
requiring XID3 would be quite cumbersome.  In this case, XID0/2 flows between 
PU2 and device1 will need to be mapped to XID3 flows between device2 and 
PU4/5.  This will be difficult and error prone.    

Since Jim points out that XID flows can be stimulated on leased SDLC and 
X.25/PVCs by coding XID=YES (both VTAM/3172 and NCP??), then I think it would 
be appropriate for us to use bits in the XID type field of XID0 to indicate 
desire for names in ACTPU/LU.    This would require changes to device1, 
device2, and PU4/5 to understand the new bit in XID0.    But with this solution 
we'd be able to provide SNA name correlation for ALL legacy PU2 devices without 
requiring an upgrade.  I think customers will find it much more acceptable to 
upgrade their VTAM/NCP and new infrastructure equipment rather than all the 
legacy devices in their network.

David Bryant
Director IBM Internetworking
3Com Corp